good catch — split the closure so StaticWOperator returns its .W field directly, only WOperator path converts now

for non-static WOperator we shouldn't unconditionally convert either.
Updated to mirror the IIP gate from #3753: use_w_reuse now requires either StaticWOperator or a WOperator whose underlying J is concrete (not an AbstractSciMLOperator). The else branch hands NonlinearSolve the cached Ww._concrete_form directly via the closure (no convert call). Matrix-free / non-concrete WOperator cases fall back to the non-w-reuse path.

fixed — now hands the operator through directly

Hi @ChrisRackauckas — quick nudge on this stack when you have a moment. All three PRs (#3795, #3796, #3798) have addressed the earlier review comments and are rebased on the latest master:

• NonlinearSolveAlg: pipe wrapprecs into inner alg and update weight per step #3795 — Added the explicit KrylovJL_GMRES() linsolve test you asked for, plus a weight-buffer check that verifies it's allocated and filled after one step.
• NLNewton OOP: handle AbstractSciMLOperator W instead of erroring #3796 — Reverted the operator convert; kept the informative error you suggested for the OOP path.
• NonlinearSolveAlg OOP: extend W-reuse to WOperator/StaticWOperator #3798 — Mirrored the IIP gate from NonlinearSolveAlg: extend W-reuse to WOperator with concrete underlying Jacobian #3753 (use_w_reuse requires StaticWOperator or a WOperator with a concrete underlying J), and now hands the operator through directly instead of Ww._concrete_form (which was stale between Newton iterations since update_coefficients! doesn't refresh _concrete_form).

Once the next SciMLOperators release tags, I'll open a follow-up here to route OOP + SciMLOperator mass matrix through WOperator and drop #3796's informative error for that path.

No rush — just wanted to make sure these weren't waiting on me. Thanks!

Ran this branch against an OOP nonlinear problem and hit two defects in the W-reuse path — posting reproductions so they can be addressed:

1. The WOperator jac closure crashes on first Jacobian use (plain Vector problems).

using OrdinaryDiffEqSDIRK, OrdinaryDiffEqNonlinearSolve, NonlinearSolve, ADTypes
using OrdinaryDiffEqNonlinearSolve: NonlinearSolveAlg
vdp(u, p, t) = [u[2], p[1] * ((1 - u[1]^2) * u[2] - u[1])]
prob = ODEProblem(vdp, [2.0, 0.0], (0.0, 1.0), [1.0e3])
integ = init(prob, TRBDF2(nlsolve = NonlinearSolveAlg(NewtonRaphson(; autodiff = AutoForwardDiff())), concrete_jac = true); reltol = 1e-8, abstol = 1e-10)
step!(integ)
# ERROR: MethodError: Cannot `convert` an object of type WOperator{false, ...} to an object of type Matrix{Float64}

The (z, p) -> Ww closure hands the raw WOperator to NonlinearSolve, whose jacobian cache holds a dense Matrix (no jac_prototype on the inner NonlinearFunction), so the assignment tries convert(Matrix, WOperator) and throws. init succeeds — it dies on the first step! that evaluates the jac, which is also why this wasn't caught: the PR currently has no tests. A test exercising exactly the TRBDF2 + concrete_jac=true + Vector u0 path above (plus a StaticArrays one for StaticWOperator) would have flagged it.

2. Even with the convert fixed, the Jacobian values are never refreshed — J is frozen at its build-time state for the entire integration.

The update in initialize! is update_coefficients!(cache.W, uprev, p, tstep; gamma = dtgamma). For WOperator that forwards to update_coefficients!(W.J, u, p, t) (SciMLOperators woperator.jl), which is a no-op when W.J is a plain matrix — and the use_w_reuse gate specifically selects for a concrete non-operator W.J. So only gamma ever updates; the J entries stay at their build_nlsolver-time values. (For StaticWOperator it's worse: Ws.W is a fixed matrix, so not even gamma changes.) Newton silently degrades to a chord iteration with J(u₀, t₀) forever — no failure on mildly nonlinear problems, just quietly worse convergence, and on strongly state-dependent J (e.g. the VdP case above) divergence→step-rejection loops.

The IIP counterpart (#3753) avoids this because _update_nlsolvealg_W! explicitly recomputes J via f.jac/jacobian! before jacobian2W!. The OOP path needs the same: an explicit J recompute (the OOP analog is calc_J/jacobian(uf, uprev, integrator)) and a W rebuild — for StaticWOperator, reconstructing StaticWOperator(J - mass_matrix * inv(dtgamma)); for WOperator, refreshing the concrete J and gamma together — inside the should_update branch.

Also worth folding in while touching this: pass jac_prototype matching W's structure to the inner NonlinearFunction — without it NonlinearSolve allocates a dense J, which is the direct cause of crash 1 and also silently densifies sparse problems (I've opened a separate PR fixing that on the IIP path).

Thanks for the review @ChrisRackauckas-Claude — both defects reproduced and fixed. New commit bd5af110:

Defect 1 (crash on convert): the OOP closure now returns the concrete matrix directly — W_ref[].W for StaticWOperator, convert(AbstractMatrix, W_ref[]) for WOperator — and I also pass jac_prototype matching that shape to the inner NonlinearFunction. NonlinearSolve no longer tries to convert(Matrix, WOperator).

Defect 2 (frozen J): added _update_nlsolvealg_W_oop! (mirrors the IIP _update_nlsolvealg_W!) — inside should_update we now recompute J via f.jac(uprev, p, tstep) or jacobian(uf, uprev, integrator), then either copyto!(W.J, J_new); W.gamma = dtgamma for WOperator or rebuild StaticWOperator(J_new - mass_matrix * inv(dtgamma)) and swap the Ref for StaticWOperator. uf is now stored in the nlcache so jacobian(uf, ...) works on the OOP path.

Ref indirection: the closure captures W_ref instead of W directly, so the StaticWOperator swap in initialize! is visible to NonlinearSolve without rebuilding the outer NonlinearProblem. For WOperator this is just a passthrough since it's already mutable.

Tests: added two regressions at the end of linear_nonlinear_tests.jl covering exactly the bot's two failure modes:

• Plain Vector VdP + TRBDF2 + concrete_jac = true — used to crash; now succeeds with njacs > 0.
• SVector VdP variant — same, exercising the StaticWOperator path.

Locally: both new tests pass; existing linear_nonlinear_tests suite still passes.

On "still concretizing": NonlinearSolveBase.construct_jacobian_cache calls safe_similar(jac_prototype) and allocates a Matrix{Float64} regardless of what the closure returns — so the OOP jac already flows through a mutable buffer once NonlinearSolveAlg is picked. If that's the real blocker, the fix belongs upstream (similar/copyto! for WOperator in SciMLOperators), not here.

That should get fixed upstream. Making everything dense is not a valid answer.

Dropped WOperator branch. W-reuse only fires on StaticWOperator + AbstractSimpleNonlinearSolveAlgorithm — SMatrix rebuilt, Ref re-pointed, no convert.

Why no WOperator?

@ChrisRackauckas Only StaticWOperator gives a real win in OOP: its W::SMatrix is immutable and stack-allocated, so nlcache.W[] = StaticWOperator(J_new - M*inv(γ)) rebuilds for free with no mutation.

For WOperator, refreshing W.J::Matrix needs either copyto!(W.J, J_new) (the mutation you rejected) or nlcache.W[] = WOperator(mm, γ, J_new, u) — the constructor allocates a fresh _concrete_form Matrix + _func_cache Vector each rebuild.

Can add a WOperator branch if you want the Vector-path coverage.